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. Kubernetes access for the assessment caller. An access entry with a suitable policy or RBAC binding, or an existing aws-auth mapping in CONFIG_MAP or API_AND_CONFIG_MAP mode, can grant the required reads. AmazonEKSViewPolicy grants Kubernetes read permissions only, no IAM permissions, and covers most namespaced workload resources but not Secrets or most cluster-scoped and extension resources (for example nodes, persistentvolumes, storageclasses, ingressclasses, CRDs, admission webhook configurations, Gateway API resources and metrics.k8s.io); confirm each read this skill needs through the connection the assessment will use. A caller without Secret list permission leaves Idle Resources SKIPPED for scoring.
3. Required AWS Permissions (minimum):
   • eks:DescribeCluster, eks:ListClusters, eks:ListNodegroups, eks:DescribeNodegroup, eks:ListFargateProfiles, eks:DescribeFargateProfile
   • ec2:DescribeInstances, ec2:DescribeInstanceTypes, 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
   • route53:ListHostedZonesByVPC, organizations:DescribeOrganization (centralized VPC endpoint zones; the account tier check)
   • elasticfilesystem:DescribeFileSystems, elasticfilesystem:DescribeLifecycleConfiguration — enables EFS Intelligent-Tiering/lifecycle checks in the storage dimension

Data Sources

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

Default Time Window

Cost Explorer queries use a 7-day lookback by default (matching the 7-day window used for CloudWatch utilization checks). The user can override the window by asking — e.g., "use the last 30 days" — in which case apply the requested window to all Cost Explorer queries. Whichever window is used, record it in the report metadata (Analysis Window field) so findings are reproducible and comparable across runs.

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

Run the account tier check in references/cost-data-collection.md (section 1.2) before the dimension checks.

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

For each kubectl target, compare the candidate context's server (kubectl --context <ctx> config view --minify -o jsonpath='{.clusters[0].cluster.server}') with the endpoint from aws eks describe-cluster --name <cluster> --region <region>. Complete this comparison before issuing Kubernetes requests. Accept a matching alias. If no context matches, stop and ask the user to add the target's kubeconfig entry. Leave current-context unchanged. Every kubectl command in this skill runs with --context <verified-context> added, even where the example omits it. For MCP instead, match the active connection to the intended cluster ARN or endpoint before reading. Stop if the binding cannot be verified. Read nodes, namespaces, pods and deployments through the verified connection before scoring, including delegated assessments. If a core read fails, stop without a score. Other denied reads make their dependent checks UNKNOWN; apply the dimension coverage rule in references/report-generation.md. On denial, report the failed read. Use the cluster's authentication mode and any available access-entry information to diagnose it. A denied entry listing leaves the entries unverified.

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>
• Fargate profiles: aws eks list-fargate-profiles --cluster-name <cluster> — if any profiles exist, describe each one, note which namespaces/label selectors are Fargate-scheduled, and read references/fargate-costs.md. Fargate pods are billed on rounded-up pod requests (not node capacity), so exclude them from node-based checks and add the Fargate-specific checks to Steps 1–2.
• 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
• Fargate pod request right-sizing against Fargate's vCPU/memory combinations — only when Step 0 found Fargate profiles (read references/fargate-costs.md, Check F1)

If no utilization metrics source is available (metrics-server, Container Insights or Prometheus), mark utilization checks as SKIPPED and proceed with request-only analysis; Compute Efficiency stays assessed on its request-based checks (4 and 5), and the report names it partly assessed.

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
• Interruption-tolerant workloads running on Fargate (EKS has no Fargate Spot) — only when Step 0 found Fargate profiles (read references/fargate-costs.md, Check F2)

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

Step 7: Score Calculation

Read references/report-generation.md for the scoring algorithm.

Apply the scoring model:

• Start at 100 points
• Apply severity-weighted deductions per dimension (capped at dimension maximum)
• Skipped dimensions contribute zero deduction and leave the denominator: the score is renormalised over the assessed dimensions
• Classify final score: OPTIMIZED (90–100), GOOD (75–89), FAIR (60–74), NEEDS_WORK (40–59), CRITICAL (0–39)

Step 8: Report Generation

Read references/report-generation.md for the report template.

Generate the report:

1. Build master finding list sorted by severity then savings
2. Generate markdown report using the template
3. Save with filename pattern: EKS-Cost-Intelligence-{cluster}-{YYYY-MM-DD}-{HHMM}.md
4. Offer HTML conversion via tools/report_to_html.py

Cost Score

The skill calculates a weighted cost efficiency score:

Score Classification:

• 90–100: OPTIMIZED — Excellent cost efficiency
• 75–89: GOOD — Minor optimization opportunities
• 60–74: FAIR — Several areas need attention
• 40–59: NEEDS_WORK — Significant waste detected
• 0–39: CRITICAL — Major cost inefficiencies across multiple dimensions

Key differences from eks-upgrade-check scoring:

• No hard-blocker override (cost issues don't prevent cluster operation)
• Severity-weighted deductions within each dimension
• Skipped dimensions renormalised out: scored at the assessed dimensions' average rate

Out of Scope (v1)

The following are intentionally excluded from the initial release and may be added in future versions:

Tool Usage Rules

1. Do NOT call any tools when this skill is first activated. Wait for the user to explicitly ask for a cost assessment.
2. Do NOT hardcode or guess cluster names. Always discover clusters by listing them first.
3. Do NOT retry a failed command more than once. If it fails twice, stop if it is a Step 0 core read. Otherwise log the failure, skip that check, and continue.
4. Always read the relevant reference file before executing checks for that dimension.
5. Use aws CLI and kubectl for cluster queries. If MCP servers are available, prefer them for EKS operations.
6. Do NOT duplicate advisory content from eks-best-practices. Reference it in recommendations where relevant.

Steering File Map

Before executing checks for any dimension, read the corresponding reference file from skills/eks-cost-intelligence/references/.

Report Output

• Markdown: EKS-Cost-Intelligence-{cluster}-{YYYY-MM-DD}-{HHMM}.md
• HTML: Run python3 ${SKILL_DIR}/tools/report_to_html.py <report>.md to convert

Do NOT generate HTML manually. Always use the conversion script.

The report includes:

• Executive summary with total estimated spend and projected savings
• Cost Score with classification and per-dimension breakdown
• Prioritized recommendations sorted by savings impact
• Per-dimension findings with remediation snippets
• Methodology and confidence notes
• Disclaimer footer

This skill is provided as sample code for educational and demonstration purposes only. Findings should be reviewed and validated before acting on them. See the project's README and LICENSE for full terms.