Eks Cost Intelligence

EKS Cost Intelligence — DevOps Agent Port

Overview

This skill performs a live cost efficiency assessment of an EKS cluster. It connects via AWS APIs and the Kubernetes API, 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?"

Prerequisites

Required IAM Permissions (Agent Space Role)

A ready-to-use IAM policy document is available at references/iam-policy.json — attach it directly to your Agent Space execution role.

The following permissions are included:

EKS (required):

• eks:ListClusters
• eks:DescribeCluster
• eks:ListNodegroups
• eks:DescribeNodegroup
• eks:ListAddons
• eks:ListFargateProfiles
• eks:DescribeFargateProfile

EC2 (required):

• ec2:DescribeInstances
• ec2:DescribeVolumes
• ec2:DescribeSubnets
• ec2:DescribeVpcEndpoints

Elastic Load Balancing (required):

• elasticloadbalancing:DescribeLoadBalancers
• elasticloadbalancing:DescribeTargetGroups
• elasticloadbalancing:DescribeTargetHealth

Cost Explorer (optional — enables dollar-accurate spend):

• ce:GetCostAndUsage
• ce:GetCostForecast

CloudWatch (optional — enables utilization-based analysis):

• cloudwatch:GetMetricData
• cloudwatch:ListMetrics
• logs:StartQuery
• logs:GetQueryResults

Amazon EFS (optional — enables EFS Intelligent-Tiering/lifecycle checks in the storage dimension):

• elasticfilesystem:DescribeFileSystems
• elasticfilesystem:DescribeLifecycleConfiguration

Kubernetes API access (required):

• The Agent Space must have Kubernetes API access to the target cluster (via EKS Access Entry or aws-auth ConfigMap)
• Required RBAC: get, list on pods, nodes, deployments, services, persistentvolumeclaims, configmaps, secrets, namespaces, events, endpointslices

When to Use

Activate when the goal involves:

• Identifying waste — "what's the biggest cost driver?" or "where am I over-provisioned?"
• Running a cost audit, cost review, or spending assessment against a live cluster
• Producing dollar-denominated findings to justify optimization work
• Cost attribution by namespace, team, or workload
• Preparing a FinOps review or cost reduction initiative
• Measuring a cluster's cost efficiency score (0-100)

Out of scope (do not assess):

• General cost optimization best practices without a live cluster — advisory guidance, not a live assessment
• Cluster design for cost efficiency — architecture decisions, not point-in-time measurement
• Operational health reviews — configuration quality, not cost posture
• Cluster discovery or reconnaissance — topology mapping, not cost analysis
• Upgrade readiness — version compatibility, not spending efficiency

Assessment Workflow

Execution model — fully autonomous. This skill runs autonomously with no interactive prompts. It proceeds through discovery and assessment without pausing for user input. When the target cluster is ambiguous, it assesses all discovered clusters. When a non-recoverable error occurs (API permission failure, no clusters found, cluster in failed state), it logs the error in the report and terminates.

Error output format:

## Assessment Error — <one-line reason>
**Condition:** <which check failed>
**What was found:** <observed state>
**Recommendation:** <remediation guidance for next run>

Step 0: Pre-flight — Cluster Discovery and Validation

Action 1 — Discover clusters

Use the EKS ListClusters API to discover available clusters in the current region.

Decision table:

Action 2 — Describe the selected cluster

Use the EKS DescribeCluster API for the target cluster. Extract: cluster name, Kubernetes version, platform version, region, status, account ID.

Action 3 — Validate cluster status

Action 4 — Gather cluster context

Collect the following using AWS and Kubernetes APIs:

• Kubernetes version and platform version (from DescribeCluster response)
• Node groups: use EKS ListNodegroups and DescribeNodegroup APIs for instance types, scaling config, capacity type (ON_DEMAND/SPOT)
• Add-ons: use EKS ListAddons API
• Fargate profiles: use EKS ListFargateProfiles API — if any profiles exist, use DescribeFargateProfile for each, 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: use Kubernetes API to list nodes with labels and capacity info
• Namespace list: use Kubernetes API to list namespaces

Action 5 — Proceed to assessment

Emit cluster summary (name, version, node count, region, account) and immediately begin Step 1. No confirmation required.

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)

Data collection uses:

• Kubernetes API to list pods with resource requests/limits per namespace
• CloudWatch Container Insights metrics (pod CPU/memory utilization) via CloudWatch GetMetricData API
• Kubernetes API to list nodes with allocatable resources and current allocations

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
• 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)

Data collection uses:

• Kubernetes API to list nodes (labels: kubernetes.io/arch, karpenter.sh/capacity-type, eks.amazonaws.com/capacityType)
• EKS DescribeNodegroup API for capacity type and instance types
• Kubernetes API to list deployments/statefulsets for affinity rules and replica counts

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

Data collection uses:

• Kubernetes API to list services (annotations for topology hints, target-type)
• Kubernetes API to list EndpointSlices (zone distribution)
• EC2 DescribeVpcEndpoints API for existing endpoints
• CloudWatch GetMetricData API for NAT Gateway bytes processed

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

Data collection uses:

• Kubernetes API to list PersistentVolumes and PersistentVolumeClaims
• Kubernetes API to list pods (volumeMounts cross-reference)
• EC2 DescribeVolumes API for volume type, size, and state
• EFS DescribeFileSystems and DescribeLifecycleConfiguration APIs

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)

Data collection uses:

• EKS DescribeCluster API (logging configuration)
• CloudWatch GetMetricData API (log group ingestion bytes)
• Kubernetes API to list ConfigMaps (FluentBit, CloudWatch agent, ADOT configs)
• Kubernetes API to list pods (environment variables for log levels)

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

Data collection uses:

• Kubernetes API to list deployments (replicas=0, last-update timestamps)
• Kubernetes API to list services of type LoadBalancer and their endpoints
• ELB DescribeTargetHealth API for backend health status
• Kubernetes API to list namespaces, resource quotas, and running pods per namespace

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
• 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 directly in markdown:

1. Build master finding list sorted by severity then savings
2. Generate markdown report using the template from references/report-generation.md
3. Use filename pattern: EKS-Cost-Intelligence-{cluster}-{YYYY-MM-DD}-{HHMM}.md

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

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 excluded entirely (not penalized)

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). If the request names a different window (e.g., "last 30 days"), 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.

Out of Scope (v1)

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

Operational Rules

1. Do NOT hardcode or guess cluster names. Always discover clusters by listing them first.
2. Do NOT retry a failed API call more than once. If it fails twice, log the failure, skip that check, and continue.
3. Always read the relevant reference file before executing checks for that dimension.
4. Do NOT duplicate general advisory content. Keep recommendations specific to cost findings with actionable remediation steps.
5. Emit findings as structured output following the schema in references/findings-format.md.

Steering File Map

Before executing checks for any dimension, read the corresponding reference file from references/.

Report Output

• Format: Markdown
• Filename: EKS-Cost-Intelligence-{cluster}-{YYYY-MM-DD}-{HHMM}.md

The agent generates the report directly — no external conversion tools required.

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.