#aws#kubernetes#mcp#devops#cloud

AWS EKS MCP Server: Managing Kubernetes Through AI Assistants

webhani·

What AWS announced at KubeCon EU 2026

KubeCon EU 2026 ran March 23–26 in Amsterdam. Among the AWS announcements, two stand out: EKS MCP Server (preview) and AWS DevOps Agent.

The practical effect: you can ask an AI assistant — Claude, GPT, or similar — to query and operate Amazon EKS clusters using natural language, with the cluster's actual state as context.

EKS MCP Server

MCP (Model Context Protocol) is the emerging standard for connecting AI agents to external tools and APIs. EKS MCP Server implements this protocol for Amazon EKS, enabling AI assistants to read cluster state and execute operations through a controlled interface.

# Install EKS MCP Server on a cluster (preview)
aws eks install-mcp-server --cluster-name my-cluster --region us-east-1
 
# Natural language queries in practice:
# "Which pods in the production namespace have restarted more than 3 times today?"
# "Scale the api-service deployment to 4 replicas"
# "Show me resource requests vs. actual usage for all pods in the backend namespace"

Before this, answering these questions required knowing the right kubectl commands and interpreting raw YAML output. The MCP layer translates cluster state into a form AI models can reason about, and translates natural language back into cluster operations.

AWS DevOps Agent

The DevOps Agent takes the MCP Server further. It's not just answering queries — it's a continuous reasoning loop that monitors cluster state, detects anomalies, and investigates root causes.

Practical scenarios:

  • A pod starts OOMKilling repeatedly. The agent correlates it with a recent deployment, identifies the changed memory limit, and surfaces the relevant commit.
  • Resource utilization trends suggest a node needs to be added before the weekend traffic spike. The agent drafts the scaling plan for a human to approve.
  • Three security groups have overlapping rules creating redundant costs. The agent flags them with remediation steps.

Thinking about permissions

Giving an AI agent access to your Kubernetes clusters requires careful IAM design. AWS builds this around least-privilege: the agent operates with exactly the permissions granted, and CloudTrail logs every action.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster",
        "eks:ListNodegroups",
        "eks:DescribeNodegroup",
        "eks:ListPodIdentityAssociations"
      ],
      "Resource": "arn:aws:eks:*:*:cluster/production-*"
    }
  ]
}

A practical starting point: read-only permissions for the AI assistant, with write operations requiring explicit human approval. Use the agent for investigation and recommendation; keep the "apply" step in human hands until you've built confidence in its judgment for your specific environment.

How this compares to Docker Kanvas

Docker Kanvas (announced earlier in 2026) converts Docker Compose files to Kubernetes manifests automatically, targeting teams that want to adopt Kubernetes without deep Helm/Kustomize knowledge.

These two tools solve different problems. EKS MCP Server is for teams already running Kubernetes who want more efficient operations. Docker Kanvas is for teams migrating to Kubernetes who want a gentler on-ramp. They're complementary, not competitive.

What this signals

The pattern of AI agents operating on live infrastructure through standardized protocols (MCP) is one of the defining trends of 2026. EKS MCP Server is a concrete example, but the same approach is appearing across cloud providers and infrastructure categories.

The infrastructure engineer's role shifts — less time writing and debugging kubectl commands, more time defining what the AI agent is allowed to do and reviewing its proposed changes. That's a meaningful change in how infrastructure work gets done.

Getting started

EKS MCP Server is in preview. Sign up through the AWS preview program, start with a non-production cluster, and constrain the initial permissions to read-only. Build up from there as you develop an understanding of how the agent reasons about your specific cluster configuration.