Eks Cost Intelligence

EKS Cost Intelligence

Overview

This skill performs a live cost efficiency assessment of your EKS cluster. It connects via AWS CLI and kubectl, analyzes cost signals across 6 dimensions, calculates a weighted Cost Score (0–100), and produces a detailed report with dollar-quantified findings, prioritized recommendations, and pre-filled remediation snippets.

This skill is focused on live cost assessment — answering the question: "Where is this cluster wasting money, and how much can I save?"

When to Use

Activate when the user:

• Asks "how much am I wasting?" or "what's my biggest cost driver?"
• Requests a cost audit, cost review, or spending assessment on a live cluster
• Needs dollar-denominated findings to justify optimization work to leadership
• Wants cost attribution by namespace, team, or workload
• Is preparing a FinOps review or cost reduction initiative
• Asks which workloads are over-provisioned relative to actual usage
• Wants to know their cluster's cost efficiency score

Do NOT activate when the user:

• Asks general cost optimization best practices → use eks-best-practices (static advisory)
• Asks "how should I design my cluster for cost efficiency?" → use eks-best-practices
• Requests an operational review or health check → use eks-operation-review
• Wants cluster discovery or reconnaissance → use eks-recon
• Asks about upgrade readiness → use eks-upgrade-check
• Asks to set up the EKS MCP server → use eks-mcp-server

Sibling Skill Disambiguation

Prerequisites

1. AWS credentials configured — aws configure or ~/.aws/credentials with EKS access
2. kubectl access to the target cluster (for Kubernetes API queries)
3. Required AWS Permissions (minimum):
   • eks:DescribeCluster, eks:ListClusters, eks:ListNodegroups, eks:DescribeNodegroup
   • ec2:DescribeInstances, ec2:DescribeVolumes, ec2:DescribeSubnets, ec2:DescribeVpcEndpoints
   • elasticloadbalancing:DescribeLoadBalancers, elasticloadbalancing:DescribeTargetHealth
4. Optional permissions (enable richer analysis):
   • ce:GetCostAndUsage — enables dollar-accurate spend data from Cost Explorer
   • cloudwatch:GetMetricData — enables utilization-based analysis from Container Insights

Data Sources

If Cost Explorer is unavailable, the skill falls back to node-based cost estimation (see references/cost-estimation-fallback.md).

MCP Server Setup

This skill works without any MCP server — it falls back to AWS CLI and kubectl commands. That fallback path is the default.

For richer operations (live cluster reads, CloudWatch metrics), enable the EKS MCP server via the eks-mcp-server skill. Once configured, this skill will prefer MCP tools over CLI for EKS operations.

Getting Started

Invoke the skill or simply ask: "Run a cost analysis on my EKS cluster"

The skill will discover your clusters, confirm which one to assess, then run the full 6-dimension assessment.

---

Assessment Workflow

Step 0: Pre-flight — Cluster Discovery

Action 1 — List clusters (test connectivity & discover clusters)

Run aws eks list-clusters to discover available clusters.

• ✅ Success → Show the cluster list. Ask which cluster to assess. If only one cluster, confirm it.
• ❌ Failure → STOP. Do NOT retry more than once. Show:

Cannot access EKS clusters. Try these steps:

1. Check that AWS credentials are configured: aws sts get-caller-identity
2. Check your region: aws eks list-clusters --region <region>
3. Verify permissions: eks:ListClusters is required

Wait for the user to resolve the issue.

Action 2 — Describe the selected cluster

Run aws eks describe-cluster --name <cluster> and show: cluster name, Kubernetes version, platform version, region, status, account ID.

Action 3 — Validate cluster status

Check the status field. If status is NOT ACTIVE:

• CREATING/UPDATING/DELETING → STOP. Show: "Cluster is currently in <status> state. Wait for the operation to complete, then re-run this assessment."
• FAILED → STOP. Show: "Cluster is in FAILED state. The cluster must be recovered before a cost assessment can be performed."

Do NOT proceed if cluster status is not ACTIVE.

Action 4 — Gather cluster context

Collect:

• Kubernetes version and platform version
• Node groups: aws eks list-nodegroups --cluster-name <cluster>
• Node group details: instance types, scaling config, capacity type (ON_DEMAND/SPOT)
• Add-ons: aws eks list-addons --cluster-name <cluster>
• Node inventory: kubectl get nodes -o wide

Action 5 — Confirm and proceed

Show the cluster summary and ask: "Ready to start the cost assessment on [cluster-name] (v[version], [N] nodes)?"

Proceed only after the user confirms.

Step 1: Compute Efficiency Assessment

Read references/compute-efficiency.md before executing checks.

Checks:

• CPU and memory request-to-utilization ratios across non-system namespaces
• Over-provisioned workloads (requests exceed utilization by threshold)
• Low-utilization nodes indicating consolidation opportunities
• Karpenter consolidation effectiveness (where installed)
• Workloads without resource requests or limits

If metrics-server or Container Insights is unavailable, mark utilization checks as SKIPPED and proceed with request-only analysis.

Step 2: Spot/Graviton Adoption Assessment

Read references/spot-graviton-adoption.md before executing checks.

Checks:

• Graviton (arm64) adoption percentage vs x86 (amd64)
• Node groups/NodePools without arm64 in allowed architectures
• Workloads with explicit amd64 affinity that could run on arm64
• Spot vs On-Demand capacity percentage
• Stateless multi-replica workloads on On-Demand only
• Instance type diversity for Spot availability
• Node Termination Handler or Karpenter interruption handling

Step 3: Networking Cost Assessment

Read references/networking-costs.md before executing checks.

Checks:

• Topology-aware routing configuration on cross-AZ services
• Instance mode vs IP mode on load balancers
• VPC endpoints for ECR, S3, STS
• Cross-AZ traffic potential based on pod distribution
• NAT Gateway cost estimation

Step 4: Storage Cost Assessment

Read references/storage-costs.md before executing checks.

Checks:

• PersistentVolumes using gp2 (flag for gp3 migration)
• PVCs bound but not mounted by any running pod
• Over-provisioned volumes (used vs provisioned capacity)
• EFS Intelligent-Tiering and lifecycle policies

Step 5: Observability Cost Assessment

Read references/observability-costs.md before executing checks.

Checks:

• EKS control plane logging configuration (all log types enabled unnecessarily)
• High-cardinality metric sources (Prometheus scrape configs, CloudWatch agent)
• DEBUG/TRACE log levels in production namespaces
• Log filtering/sampling configurations (FluentBit, CloudWatch agent)

Step 6: Idle Resource Detection

Read references/idle-resources.md before executing checks.

Checks:

• Deployments scaled to zero replicas for extended periods
• LoadBalancer Services with no healthy backend endpoints
• Namespaces with no running workloads but allocated quotas
• Orphaned ConfigMaps and Secrets not referenced by running workloads