Your Kubernetes cluster is probably 60% empty air, and you're paying full price for it. Here's the uncomfortable truth most teams discover the first time they actually measure it: pods request 2 CPU and 4Gi of memory, then sit there using 180m and 900Mi. The scheduler reserves the full request, so your nodes fill up on paper while the actual silicon idles. You end up adding nodes you don't need to run workloads that barely breathe. The old fix was to stare at Grafana for an afternoon and hand-tune YAML. The new fix is to let an AI agent do the reading for you. Start with the data. Run this: kubectl top pods -n production --containers Then pull what each pod actually requested: kubectl get pods -n production -o json | jq '.items[] | {name: .metadata.name, resources: [.spec.containers[].resources]}' Now you have two numbers per pod: what it reserved vs. what it uses. Paste both into Claude, GPT-4, or Gemini with a prompt like: "Here is kubectl top output and the configured requests for these pods. For each pod, recommend right-sized CPU and memory requests with 20% headroom. Memory is non-compressible, so never go below observed peak. Output a YAML patch." The model returns structured recommendations in seconds, complete with the reasoning for each one. Real numbers from a mid-size cluster I looked at: 42 pods, average CPU utilization against requests was 14%, memory 31%. Right-sizing dropped the reserved footprint enough to remove 3 of 11 m5.xlarge nodes. That's roughly $420/month per node on-demand, so about $1,260/month, or $15k/year, from one afternoon of work. Two guardrails before you get excited. First, never trust a single snapshot. kubectl top is a point in time. Look at 7-day P95, not the number at 2pm on a Tuesday. Second, treat CPU and memory differently. CPU is compressible, so an under-provision means throttling. Memory is not, so an under-provision means OOMKilled. Tell your AI agent this explicitly or it will happily suggest a memory request that kills your pod under load.

Last week one of my clients spent 3 hours debugging a CrashLoopBackOff. The fix took 45 seconds once we knew what to look at. The investigation took 3 hours. That's the real Kubernetes tax — not the cluster cost, the engineer time. Here's the workflow I now use instead: Step 1 — Grab the raw context. Three commands: kubectl describe pod <pod-name> -n <namespace> kubectl logs <pod-name> -n <namespace> --previous kubectl get events -n <namespace> --sort-by='.lastTimestamp' Step 2 — Feed it to Claude or GPT-4 with this prompt: "You are a senior Kubernetes SRE. I have a pod failing in production. Here is the output of kubectl describe, previous logs, and recent events. Identify the root cause, explain why it's happening, and give me the exact fix with kubectl or YAML changes. Flag any security or resource misconfiguration you spot while you're in there." Paste all three outputs. Step 3 — Get a diagnosis in 30 seconds. Last week's result for that client: OOMKilled container with a memory limit of 128Mi trying to load a 400MB ML model. The AI spotted it immediately, suggested the right limit (1.5Gi), and flagged that the pod had no resource requests set — which was causing noisy neighbor problems on the node. The AI also noticed the liveness probe was firing before the app finished loading, which was masking the real issue in older logs. Two config changes. Done. What makes this work is the combination of context: describe output shows resource limits and probe config, previous logs catch the last gasp before the crash, and events show the timeline. Most people only look at one of these. I've built a library of 7 prompts covering the most common K8s failure modes — CrashLoopBackOff, OOMKill, Pending pods, ImagePullBackOff, probe failures, init container failures, and a security audit prompt. Each one is tuned to pull out the exact signals AI needs to give a useful diagnosis. Drop a comment below and I'll share the full prompt library with you. What's the most annoying Kubernetes failure you keep running into? Drop it below — I'll write a prompt for it.

Last quarter a client asked me to review their Azure bill. $180,000/month. They thought it was roughly correct for their workload. It wasn't. After 90 minutes of feeding Azure data into Claude with the right prompts, we found $23,000/month in waste they had no idea was there. Here's exactly what we did and how you can run the same audit yourself. THE FIVE-STEP AZURE AI COST AUDIT Step 1: Export your Azure Cost Management data. In the Azure portal: Cost Management > Cost Analysis > Download. Export last 90 days as CSV. Or via CLI: az costmanagement export create --name "90day-audit" --type ActualCost --scope "/subscriptions/YOUR_SUB_ID" --dataset-granularity Daily Step 2: Pull Azure Advisor cost recommendations. az advisor recommendation list --category Cost -o json > advisor-recommendations.json Step 3: Find orphaned resources with Azure Resource Graph. az graph query -q "Resources | where type =~ 'microsoft.compute/disks' | where properties.diskState =~ 'Unattached' | project name, resourceGroup, properties.diskSizeGB, location | order by properties.diskSizeGB desc" -o json Step 4: Feed everything into Claude with this prompt: "You are an Azure FinOps consultant. I'm sharing: (1) Azure Cost Management export last 90 days, (2) Azure Advisor cost recommendations JSON, (3) orphaned resource inventory. Provide: top 5 cost drivers, Advisor recommendations ranked by monthly savings/effort ratio, estimated waste from orphaned resources with specific resources to delete, and three changes I can make THIS WEEK to reduce the bill immediately." Step 5: Validate findings with Azure Cost Management's What-If forecast before acting. WHAT WE ACTUALLY FOUND ($180K/MONTH CLIENT) $8,400/month: 23 stopped VMs still provisioned -- nobody deallocated them after a migration project $6,200/month: 840GB unattached premium managed disks from a test environment shut down 14 months ago $4,100/month: Oversized App Service Plans (P3v3 where P1v3 handles the load -- Advisor flagged this for 6 months, ignored)

Three months ago a client's AWS account got compromised. The attacker didn't exploit a zero-day. They found a developer role with iam:PassRole and sts:AssumeRole on *, combined it with an existing Lambda execution role, and quietly escalated to admin. The IAM change that enabled it passed code review. Nobody caught it. I've been pasting IAM changes into Claude before every deploy since then. Here's the exact prompt I use: "You are a cloud security architect. Review the following IAM policy/role change for: 1. Privilege escalation paths (iam:PassRole, sts:AssumeRole, iam:CreatePolicyVersion, iam:AttachUserPolicy, lambda:CreateFunction combos) 2. Overly broad resource scope (* where a specific ARN should be used) 3. Missing condition keys (aws:SecureTransport, aws:RequestedRegion, MFA conditions) 4. Least-privilege violations - permissions granted beyond stated purpose 5. Data exfiltration risks (s3:GetObject on *, logs:CreateExportTask, ec2:CreateSnapshot combos) For each finding: severity (Critical/High/Medium/Low), explanation, and the corrected policy JSON. IAM change: [PASTE YOUR POLICY OR TERRAFORM PLAN OUTPUT]" What it catches that code review misses: The escalation combos. Humans review individual permissions. AI sees the combinations. iam:PassRole alone is fine. iam:PassRole + iam:CreateRole + lambda:CreateFunction = admin escalation path. Claude maps these automatically. The * scope creep. Every team starts with least privilege and drifts. "We needed it to work fast" is how you end up with s3:* on *. Claude flags every * and asks why. Missing conditions. An S3 bucket policy with no aws:SecureTransport condition. An assume-role without an external ID. A cross-account trust policy with no MFA requirement. These slip through review constantly. How to integrate it into your workflow: If you use Terraform: paste the terraform plan output and ask Claude to identify IAM changes and audit them. It extracts the IAM diffs automatically. If you use AWS CDK: run cdk diff, pipe the IAM section to Claude.

Six months ago I added a simple step to my Terraform workflow: before any PR, I paste the plan output into Claude and ask it to identify security issues, cost surprises, and configuration mistakes. It's caught things my team missed every single week. Here are the five categories of issues it finds most often: 1. OVERLY PERMISSIVE IAM POLICIES 2. The most common catch. Engineers write "*" for actions because it's convenient and they mean to tighten it later. Claude flags this immediately and suggests the minimal policy set for the specific resource being created. This is the one that saves you the most pain downstream. 3. MISSING LIFECYCLE RULES ON S3 / GCS BUCKETS 4. Storage that fills up forever is a slow budget drain. Claude catches missing lifecycle policies and asks: do you want objects in this bucket deleted or archived after X days? Most of the time the answer is yes, and it's been forgotten. 5. UNENCRYPTED RESOURCES 6. RDS instances, EBS volumes, Redshift clusters without encryption_at_rest. These are easy to miss in large Terraform files. Claude spots them consistently. 7. PUBLIC EXPOSURE RISKS 8. Security groups with 0.0.0.0/0 inbound on ports that shouldn't be public, S3 buckets with public access, load balancers without HTTPS-only listeners. Claude treats these as high-priority flags. 9. RESOURCE SIZING MISMATCHES 10. The most expensive one long-term. Claude will look at what you're deploying and ask "are you sure you need an r6g.4xlarge for a dev environment?" It doesn't know your context, but asking the question is enough to catch obvious over-provisioning. THE PROMPT I USE: "You are a Cloud Security and FinOps expert. Review this Terraform plan output. Identify: (1) security risks with severity level, (2) cost optimization opportunities, (3) configuration mistakes, (4) best practice violations. Be specific about resource names. Do not give generic advice." I paste the full output of terraform plan or terraform show -json processed through jq.